1. Field of the Invention
The present invention is directed to routing Email within an administrative email domain or set of domains, which in one embodiment to an email service facility housing a number of users, and in particular to a method for configuring mail routing in a private email domain service provider.
2. Description of the Related Art
Perhaps the most prevalent use of the Internet is communication via electronic mail. One of the most common forms of email is provided by Email Service Providers (ESPs) such as Yahoo! Mail, Microsoft Hotmail, Google GMail, and other free web-based email services.
Generally, such ESPs direct users running web-browsers to a cluster of computers which provide an email application to the user via the web-browser interface. However, other methods of accessing free email services, such as Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) may be utilized. Mail directed to users having accounts associated with the ESP domain are likewise directed to the ESP's Message Transfer Agents (MTAs), which work with other devices within the ESP's server structure. In an architecture having a large number of mailboxes in a single location, mail acceptance servers are typically separated from storage servers, and there are generally many machines of each type.
Once the architecture separates the internal MTAs from the storage servers, the ESP architecture requires a methodology for routing mail internally. Current systems generally implement proprietary internal routing protocols that require each mail message to be processed again, often by an intermediate set of servers, to ensure routing of mail data to the actual storage servers is conducted accurately. However, this additional processing is resource intensive.
When individuals forward mail externally, mail typically goes from an originating E-mail client to an SMTP server. The SMTP server then retrieves/consults the MX record(s) of the domain in the E-mail address. For example, with “joe@example.com”, the SMTP server would look for the MX records for example.com. In that example, the SMTP server might find the MX record of “mail.example.com”. The MX record is a domain name, so the SMTP server then gets the address (“A”) record for that domain name, and connects to the mail server. Each MX record has 2 pieces of information associated with it. The first is a preference number, and the second is the domain name of a mail server. If there are multiple MX records, the SMTP server will pick one based on the preference level, starting with the lowest preference number and working up. It is acceptable to have more than one MX record with the same preference.
A mechanism for simplifying and/or enhancing the routing of email messages in a administrative domain, such as an ESP, would be advantageous.